home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 15483 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.5 KB

  1. Path: lrz-muenchen.de!news
  2. From: watzka@stat.uni-muenchen.de (Kurt Watzka)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Why are &apple and apple, where apple is an array, the same
  5. Date: 19 Apr 1996 08:27:13 GMT
  6. Organization: Leibniz-Rechenzentrum, Muenchen (Germany)
  7. Distribution: world
  8. Message-ID: <4l7ip1$ft4@sparcserver.lrz-muenchen.de>
  9. References: <AD9C7BE9966828AF7@ad49-131.compuserve.com>
  10. NNTP-Posting-Host: sun2.lrz-muenchen.de
  11.  
  12. 101641.317@compuserve.com (Martin Mamo) writes:
  13.  
  14. >The following C program contains two printf's. They both
  15. >give the same answer, despite the fact one gives the
  16. >value of apple and the other &apple.
  17.  
  18. And the behaviour of the program is undefined anyway, so why
  19. are you surprised by that.
  20.  
  21. >I know in C, an array variable is the address of the
  22. >first element.
  23.  
  24. In C an array variable is, well, an array variable. Used in
  25. an expression (with some minor exceptions) an array name
  26. decays to the address of the first element.
  27.   
  28. >So why do C compilers on both Macs and PCs
  29. >allow you to take an address of an address?
  30.  
  31. You take the address of an array, which is perfectly legal in C.
  32.  
  33. >Why does
  34. >apple and &apple, where apple is an array variable, give
  35. >the same result.
  36.  
  37. Because both give you a pointer to the beginning of "apple".
  38.  
  39. >Please can you reply by e-mail to me as well, as I check
  40. >newsgroups less often than my e-mail. Thanks.
  41.  
  42. So you will obviously have to wait until you check this
  43. newsgroup again until you read this answer. If you want to
  44. save bandwidth, as for e-mail replies and offer to post
  45. a summary.
  46.  
  47. >#include <stdio.h>
  48.  
  49. >void main(void)
  50.  
  51. I will not comment on this.
  52.  
  53. >{
  54.  
  55. >    char apple[10];
  56. >    apple[0] = 0;
  57. >    
  58. >    printf( "%lu\n", apple );
  59.  
  60. "apple" is a "char *" in this context, and you can print it 
  61. with printf using "printf("%p\n", (void *) apple)". Whether
  62. the cast to "void *" is needed in this situation may be open
  63. to debate because the internal representation of a "char *"
  64. cannot be different from the internal representation of a
  65. "void *" in C.
  66.  
  67. >    printf(" %lu\n", &apple );
  68.  
  69. "apple" is a "char (*)[10]" in this context, and you can
  70. print it with printf using "printf("%p\n", (void *)&apple)".
  71. The internal representation of a pointer to an array of 10
  72. char can be different from the internal representation of a 
  73. "void *", so the cast _is_ necessary in this context.
  74.  
  75. >}
  76.  
  77. See the FAQ for comp.lang.c for a _good_ explanation of
  78. "arrays" and "pointers".
  79.  
  80. Kurt
  81. --
  82. | Kurt Watzka                             Phone : +49-89-2180-6254
  83. | watzka@stat.uni-muenchen.de
  84.